packages/sdk-utilities/src/lib/wellknown/wellknown.utils.ts (1)

85-98: Consider adding IPv6 localhost support.

The function allows HTTP for localhost and 127.0.0.1, but not for ::1 (IPv6 localhost) or [::1]. This is a minor edge case but could cause unexpected behavior in IPv6-only development environments.

♻️ Optional: Add IPv6 localhost support

     // Allow HTTP only for localhost (development)
-    const isLocalhost = url.hostname === 'localhost' || url.hostname === '127.0.0.1';
+    const isLocalhost =
+      url.hostname === 'localhost' ||
+      url.hostname === '127.0.0.1' ||
+      url.hostname === '[::1]' ||
+      url.hostname === '::1';
     const isSecure = url.protocol === 'https:';
     const isHttpLocalhost = url.protocol === 'http:' && isLocalhost;

packages/oidc-client/src/lib/wellknown.api.ts (2)

33-38: Selector created on every call defeats memoization.

createSelector is invoked inside the function body, creating a new memoized selector on each call to wellknownSelector. This negates the memoization benefits since each call produces a fresh selector instance.

Consider creating the selector once per wellknownUrl or using createWellknownSelector from the re-exported utilities if it handles this pattern.

♻️ Option: Cache selectors by URL

+const selectorCache = new Map<string, ReturnType<typeof createSelector>>();
+
 export function wellknownSelector(wellknownUrl: string, state: RootState) {
-  const selector = createSelector(
-    wellknownApi.endpoints.configuration.select(wellknownUrl),
-    (result) => result?.data,
-  );
+  let selector = selectorCache.get(wellknownUrl);
+  if (!selector) {
+    selector = createSelector(
+      wellknownApi.endpoints.configuration.select(wellknownUrl),
+      (result) => result?.data,
+    );
+    selectorCache.set(wellknownUrl, selector);
+  }
   return selector(state);
 }

Alternatively, if createWellknownSelector (already exported) provides this functionality, consider using it directly instead of this wrapper.

---

18-21: Consider combining export and import statements.

The separate re-export (line 18) and import (line 21) from the same package can be consolidated.

♻️ Suggested consolidation

-export { wellknownApi, createWellknownSelector } from '@forgerock/sdk-oidc';
-
-// Import locally for use in selector below
-import { wellknownApi } from '@forgerock/sdk-oidc';
+import { wellknownApi, createWellknownSelector } from '@forgerock/sdk-oidc';
+
+export { wellknownApi, createWellknownSelector };

packages/journey-client/src/lib/wellknown.utils.test.ts (1)

64-69: Consider adding a comment explaining intentional type casts.

The type assertions (as AsyncJourneyClientConfig, as JourneyClientConfig) are used to bypass TypeScript's checks and test edge cases with invalid inputs. A brief comment would clarify this intent for future maintainers.

         const config: JourneyConfigInput = {
           serverConfig: {
             baseUrl: 'https://am.example.com/am/',
             wellknown: '',
           },
-        } as AsyncJourneyClientConfig;
+        } as AsyncJourneyClientConfig; // Intentionally cast to test runtime behavior with empty wellknown

package.json (1)

52-52: Empty dependencies object is unnecessary.

The root package.json typically doesn't need a dependencies field for a monorepo. If this was added intentionally for a specific tooling requirement, consider adding a comment explaining its purpose; otherwise, it can be removed.

packages/oidc-client/src/lib/wellknown.api.ts (1)

12-38: Use the shared selector factory instead of recreating selectors.

The createWellknownSelector helper from @forgerock/sdk-oidc returns a memoized selector function, which can be directly called with state. Refactoring to use it aligns with the documented intent and avoids recreating the selector on each call.

♻️ Proposed refactor

-import { createSelector } from '@reduxjs/toolkit';
-
 import type { RootState } from './client.types.js';

 /**
  * Re-export the shared wellknown RTK Query API from `@forgerock/sdk-oidc`.
@@
 export { wellknownApi, createWellknownSelector } from '@forgerock/sdk-oidc';

 // Import locally for use in selector below
-import { wellknownApi } from '@forgerock/sdk-oidc';
+import { wellknownApi, createWellknownSelector } from '@forgerock/sdk-oidc';

@@
 export function wellknownSelector(wellknownUrl: string, state: RootState) {
-  const selector = createSelector(
-    wellknownApi.endpoints.configuration.select(wellknownUrl),
-    (result) => result?.data,
-  );
-  return selector(state);
+  return createWellknownSelector(wellknownUrl)(state);
 }

e2e/davinci-app/package.json (1)

19-19: Optional: drop empty devDependencies block.
Keeps the manifest leaner if no dev-only deps are required.

♻️ Proposed cleanup

-  "devDependencies": {},

package.json (1)

52-52: Optional: remove empty dependencies.
Avoids a redundant block if not needed.

♻️ Proposed cleanup

-  "dependencies": {},

packages/journey-client/src/lib/device/device-profile.test.ts (1)

10-10: Type update from SpyInstance to Mock is correct.

The change aligns with Vitest's API evolution where SpyInstance was deprecated in favor of Mock. However, the explicit callable signatures in the generic parameter are verbose and may not be necessary.

Consider simplifying to:

let warnSpy: Mock<typeof console.warn>;

This achieves the same type safety with less boilerplate.

Also applies to: 89-92

packages/sdk-utilities/src/lib/wellknown/wellknown.utils.test.ts (1)

12-72: Test coverage is good; consider simplifying nested describe blocks.

The test cases cover the main validation scenarios well. However, the nested describe blocks are redundant—each wraps only a single it() and duplicates the test description.

♻️ Suggested simplification

 describe('isValidWellknownUrl', () => {
-  describe('isValidWellknownUrl_HttpsUrl_ReturnsTrue', () => {
-    it('should return true for HTTPS URL', () => {
-      expect(isValidWellknownUrl('https://am.example.com/.well-known/openid-configuration')).toBe(
-        true,
-      );
-    });
-  });
+  it('should return true for HTTPS URL', () => {
+    expect(isValidWellknownUrl('https://am.example.com/.well-known/openid-configuration')).toBe(
+      true,
+    );
+  });
   // ... similarly for other test cases

Additionally, consider adding edge cases:

• URLs without ports (e.g., https://am.example.com/.well-known/openid-configuration)
• URLs with query strings or fragments
• Null/undefined inputs (if the function signature allows)

packages/journey-client/src/lib/config.types.ts (1)

32-50: Reduce duplication by extending PathsConfig.
WellknownServerConfig mirrors PathsConfig fields. Extending PathsConfig keeps future additions consistent.

♻️ Proposed refactor

-export interface WellknownServerConfig {
-  /** Base URL for AM-specific endpoints (authenticate, sessions) */
-  baseUrl: string;
-  /** URL to the OIDC well-known configuration endpoint */
-  wellknown: string;
-  /** Custom path overrides for endpoints */
-  paths?: PathsConfig['paths'];
-  /** Request timeout in milliseconds */
-  timeout?: number;
-}
+export interface WellknownServerConfig extends PathsConfig {
+  /** URL to the OIDC well-known configuration endpoint */
+  wellknown: string;
+}

packages/journey-client/src/lib/journey.api.ts (1)

118-123: Consider extracting config retrieval into a helper function.

The same config retrieval and validation pattern is repeated in start, next, and terminate endpoints (lines 118-123, 152-157, 183-188). A helper could reduce duplication:

♻️ Optional refactor

function getConfigFromState(api: BaseQueryApi): { realmPath?: string; serverConfig: ServerConfig } {
  const state = api.getState() as JourneyRootState;
  const config = state.journey.config;
  if (!config?.serverConfig) {
    throw new Error('Server configuration is missing.');
  }
  return { realmPath: config.realmPath, serverConfig: config.serverConfig };
}

Then in each endpoint:

-const state = api.getState() as JourneyRootState;
-const config = state.journey.config;
-if (!config?.serverConfig) {
-  throw new Error('Server configuration is missing.');
-}
-const { realmPath, serverConfig } = config;
+const { realmPath, serverConfig } = getConfigFromState(api);

packages/journey-client/src/lib/client.store.ts (1)

131-135: Structured error information is discarded.

createWellknownError returns a GenericError with error, message, type, and status fields, but only message is used when throwing. Consider preserving the structured error or using a custom error class:

♻️ Preserve structured error information

Option 1 - Create a custom error class:

class WellknownError extends Error {
  constructor(public readonly genericError: GenericError) {
    super(genericError.message);
    this.name = 'WellknownError';
  }
}
// Usage:
throw new WellknownError(genericError);

Option 2 - Add cause to the error:

-throw new Error(genericError.message);
+throw new Error(genericError.message, { cause: genericError });